Notice and non-response tracking

ABSTRACT

Tracking and management data for distribution of informational, legal, or contractual notices and tracking associated response, or non-response, is disclosed. The system generates and links tracking data for both the distribution and the response, generates indicators that include the tracking data, and encodes the indicators so that the indicators are detectable as they traverse various events and locations throughout the lifecycle. A detailed audit trail of each event in the distribution and response lifecycle is constructed using data matching methods and various statistics regarding the lifecycle, such that the response habits of notice recipients are formulated.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/427,225 entitled “Lifecycle Tracking and Management Using RF,” filedon Apr. 21, 2009. The '225 application is a continuation-in-part of U.S.patent application Ser. No. 12/044,781 entitled “Solicitation-ResponseLifecycle Tracking and Management,” filed Mar. 7, 2008, both of whichare incorporated by reference in their entirety.

FIELD OF THE INVENTION

The present invention generally relates to tracking and management data,and more particularly, to providing more accurate and more detailedinformation related to tracking notices and associated responses.

BACKGROUND OF THE INVENTION

Modern organizations often need to access data to manage theirenterprises effectively. Generally, more accurate and more timely dataenables improved product quality, improved customer service, lower costsand higher profitability. The vast amount of capital resources, humanresources and physical resources that a typical organization commits tocollecting, processing and analyzing data typically indicates the valueto an organization of accurate and timely data. Information regardingcustomer activity and preferences is of particular value. Customers arethe key to success for most organizations, whether the customers arecurrent revenue producing customers, potential customers or constituentsin a government or non-profit organization. Therefore, organizationsspend large amounts of time, effort and money collecting, monitoring,evaluating, analyzing and forecasting customer activity. The datacollected about customers may be as broad as an industry or marketstudy, or as narrow as how a particular demographic or individualcustomer responds to a directed solicitation. Organizations use thisdata, for example, to optimize operations, improve financialperformance, formulate product strategy, target marketing efforts andformulate plans from the broadest strategic vision down to the mostdetailed operational detail.

One type of customer data that is often valuable to an organizationrelates to timing with which a customer or potential customer respondsto a solicitation. For instance, rapid turnaround of a marketingsolicitation may indicate a healthy, eager demand for a particularproduct or service. Similarly, quick payment of a bill may indicate ahappy customer, a financially sound customer and/or a customer thatprefers to minimize outstanding debt.

Detailed information related to customer payment habits is of particularinterest to an organization's financial operation because theinformation is often used to better forecast cash flows, to modifybilling procedures and to increase rapid payment of bills. Due to theimportance of cash in running a business, it is usually in a company'sbest interest to collect outstanding receivables as quickly as possible.Organizations typically calculate the average collection period as theapproximate amount of time that it takes for a business to receivepayments owed from its customers and clients. Many businesses allowcustomers to purchase goods or services via credit, but one of theproblems with extending credit is not knowing when the customer willmake cash payments. Therefore, decreasing the average collection periodis often desirable because this means that it does not take a companyvery long to turn its receivables into cash. See, for instance,http://www.investopedia.com for general information regarding theimportance to organizations of converting receivables into cash.

Organizations usually employ many different strategies, technologies andmethods in an attempt to reduce the average collection period forreceivables. One approach is to optimize remittance collection bygetting bills into the hands of the customers who are most willing orable to pay the bills. In some billing organizations, this approach iscalled customer-based work prioritization. Such prioritization iscrucial for organizations with complex billing processes and largebilling volumes. For such organizations, access to granular data thatprovides visibility into each discrete event, and the duration betweenthese events, in the bill-to-payment lifecycle is typically critical.These events are not readily tracked by current methods and solutionsfor tracking a correspondence. Current solutions only provide a roughestimate of the actual time between when a customer receives a bill andwhen the customer remits payment of the bill. Therefore, a long-feltneed exists for a method to determine much more precisely when thecustomer sends the remittance and to link the tracking informationgathered for the bill to the tracking information gathered for theremittance.

SUMMARY OF THE INVENTION

The present invention improves upon existing systems and processes byproviding a tangible, integrated, end-to-end notice distribution andresponse lifecycle tracking mechanism. When an organization distributesa contractual, informational or legal notice to a customer and alsoprovides a way for the customer to respond (e.g. by redeeming a coupon),the system generates tracking data for both the distribution and theresponse. Tracking data is linked such that tracking informationcollected for the distribution is linked to tracking information for theresponse. Indicators are generated that encode the tracking data and theindicators are attached to the outgoing solicitation and the incomingresponse. Service providers (e.g., the U.S. Postal Service (“USPS”),FedEx®, etc.) detect the indicator and store additional informationregarding the time, place and status of the detected parcel. A datatransfer or data sharing method provides access to the service providerdata and the data is matched using various methods. A detailed audittrail of each event in the distribution and response lifecycle isconstructed. Various statistics regarding the lifecycle, andspecifically the response habits of customers, is also formulated.

In one embodiment, a method includes: i) receiving first distributiontracking data from a service provider, where the first distributiontracking data is based upon detection of a first distribution trackingindicator associated with a notice, and where a first notice trackingidentifier is associated with the first distribution tracking indicator,and where the first notice tracking identifier is one of a plurality ofnotice tracking identifiers each associated with a respectivedistribution tracking indicator and each respective distributiontracking indicator configured to be detected; ii) matching a firsttracking dataset with the first distribution tracking data to creatematched tracking data, where the first tracking dataset is one of aplurality of tracking datasets; and iii) analyzing the matched trackingdata to determine whether the notice distribution metrics.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the invention may be derived byreferring to the detailed description and claims when considered inconnection with the Figures, wherein like reference numbers refer tosimilar elements throughout the Figures, and:

FIG. 1 is an overview of a representative system for tracking thelifecycle of a solicitation within a billing and payment managementsystem, in accordance with one embodiment of the present invention.

FIG. 2 is a representative process flow diagram for tracking lifecycledata, in accordance with one embodiment of the present invention.

FIG. 3 is a representative process flow diagram for collecting lifecycletracking data, matching it with other identifying data and storing thematched data in a management reporting database, in accordance with oneembodiment of the present invention.

FIG. 4 is a representative process for mapping the lifecycle data tobusiness events and performing calculations to enhance the businessvalue of the data, in accordance with one embodiment of the presentinvention.

FIG. 5 is a representative process for tracking a solicitationthroughout a multi-stage process, in accordance with one embodiment ofthe present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The detailed description of exemplary embodiments of the inventionherein makes reference to the accompanying drawings, which show theexemplary embodiment by way of illustration and its best mode. Whilethese exemplary embodiments are described in sufficient detail to enablethose skilled in the art to practice the invention, it should beunderstood that other embodiments may be realized and that logical andmechanical changes may be made without departing from the spirit andscope of the invention. Thus, the detailed description herein ispresented for purposes of illustration only and not of limitation.

For the sake of brevity, conventional data networking, applicationdevelopment and other functional aspects of the systems (and componentsof the individual operating components of the systems) may not bedescribed in detail herein. Furthermore, the connecting lines shown inthe various figures contained herein are intended to represent exemplaryfunctional relationships and/or physical couplings between the variouselements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical system.

In one embodiment, the system includes a billing and management system,a billing system, a lifecycle management and reporting module, anapplication server, a data download module and various databases. Whilethe system may contemplate upgrades or reconfigurations of existingprocessing systems, changes to existing databases and businessinformation system tools are not necessarily required by the presentinvention. For example, the present system may contemplate, but does notrequire, downloading data from a service provider (e.g., USPS) usingfile transfer protocol (FTP). Moreover, the system may be seamlesslyintegrated into existing information technology and data managementarchitectures and business information system tools with minimal changesto existing systems.

“Organization,” as used herein, may include any individual, group,business, entity, government entity, transaction account issuer (e.g.,credit, charge, etc), merchant, consortium of merchants, customer,account holder, charitable organization, software, hardware, and/or anyother entity or party.

A “soliciting organization” includes any organization, software and/orhardware that contacts another organization or person such as, forexample, a customer. A soliciting organization often contacts anotherentity and expects to receive some response. As used herein, a“solicitation” includes any form of communication (e.g. a bill,marketing piece, etc) directed to a responding entity. A “respondingentity” includes any organization, software and/or hardware such as, forexample, a customer, potential customer or account holder to which asolicitation is directed. A “receivable” may include any physical orlogical record or other tracking mechanism that serves to identify anexpectation that the organization will receive a response from asolicitation. In one embodiment, one of the valid forms of an expectedresponse may be defined as a non-response. For example, a marketingorganization may send a customer survey to a set of potential customers,track the expectation of a response from each customer as a separate“receivable,” and define the lack of a response as a valid response tothe survey for tracking and reporting purposes.

In one embodiment, a “billing organization” includes a solicitingorganization (or department within a larger organization) hardwareand/or software that generates, distributes, tracks, etc. customer billsand payments. A billing organization may generate an invoice, aremittance and a receivable which represents the expectation that theinvoice be paid via the remittance mechanism.

Intelligent Mail Barcode (“IMB”) is a specially formatted bar codedefined and specified by the USPS used to enable various trackingservices. IMB is fully specified by the USPS publication INTELLIGENTMAIL® BARCODE (4-STATE CUSTOMER BARCODE), available athttp://ribbs.usps.gov/OneCodeSOLUTION/SPUSPS-B-3200E001.pdf, which ishereby incorporated by reference.

An “indicator”, as used herein, may include an IMB, a radio frequencyidentifier (RFID), a global positioning system (GPS) signal, a signal, acode, device, number, letter, symbol, digital certificate, smart chip,digital signal, analog signal, biometric, personal identification number(PIN), Internet code, magnetic stripe, optical, transponder and/or otheridentifier/indicia suitably configured to allow detection and/or datacommunication.

An “account”, “account number” or “customer account” as used herein, mayinclude any device, code (e.g., one or more of an authorization/accesscode, PIN, Internet code, other identification code, and/or the like),number, letter, symbol, digital certificate, smart chip, digital signal,analog signal, biometric or other identifier/indicia suitably configuredto allow the consumer to access, interact with or communicate with thesystem. The account number may optionally be located on or associatedwith a rewards card, charge card, credit card, debit card, prepaid card,telephone card, embossed card, smart card, magnetic stripe card, barcode card, transponder, radio frequency card or an associated account.The system may include or interface with any of the foregoing cards ordevices, or a fob having a transponder and RFID reader in RFcommunication with the fob. Although the system may include a fobembodiment, the invention is not to be so limited. Indeed, the systemmay include any device having a transponder which is configured tocommunicate with an RFID reader via RF communication. Typical devicesmay include, for example, a key ring, tag, card, cell phone, wristwatchor any such form capable of being presented for interrogation. Moreover,the system, computing unit or device discussed herein may include a“pervasive computing device,” which may include a traditionallynon-computerized device that is embedded with a computing unit. Examplesmay include watches, Internet enabled kitchen appliances, restauranttables embedded with RF readers, wallets or purses with imbeddedtransponders, etc.

The account number may be distributed and stored in any form of plastic,electronic, magnetic, radio frequency, wireless, audio and/or opticaldevice capable of transmitting or downloading data from itself to asecond device. A customer account number may be, for example, asixteen-digit credit card number, although each credit provider has itsown numbering system, such as the fifteen-digit numbering system used byAmerican Express. Each company's credit card numbers comply with thatcompany's standardized format such that the company using asixteen-digit format will generally use four-spaced sets of numbers, asrepresented by the number “0000 0000 0000 0000”. The first five to sevendigits are reserved for processing purposes and identify the issuingbank, card type, etc. In this example, the last (sixteenth) digit isused as a sum check for the sixteen-digit number. The intermediaryeight-to-ten digits are used to uniquely identify the customer. Amerchant account number may be, for example, any number or alpha-numericcharacters that identify a particular merchant for purposes of cardacceptance, account reconciliation, reporting, or the like.

Exemplary benefits provided by this invention include increasing cashflow, optimizing financial operations, enabling customer-focused workprioritization, enhancing knowledge about customer activity and habits,enhancing customer functionality and satisfaction, enhancing the abilityto certify compliance with regulatory requirements, and linkingsolicitation events to response events. The tool enables tracking datafor both the solicitation and the response. The two sets of trackingdata are linked so that tracking information collected for thesolicitation is linked to tracking information for the response. Theinvention improves upon existing solutions because existing systemseither provide no visibility, or, at best, provide poor or unreliabledata regarding a more precise duration of each event during asolicitation and response lifecycle. In one embodiment, the tool enablesenhanced marketing operations by allowing marketing materials to betracked. In one embodiment, the tool is used to track legal disclosures,member or customer agreements, can compliance to regulatory servicelevel agreements.

While described herein in reference to tracking and maintaining billingand accounts receivable metrics for a transaction account issuerorganization, practitioners will appreciate that the invention mayfurther be implemented to increase speed, lower cost and improve cashflow management in a wide variety of industries. For instance, oneembodiment may be implemented for a wireless phone company's billingoperation that wishes to collect detailed, granular data regarding theirbill-to-payment lifecycle. Other examples of such accounts receivableand payment tracking may be accomplished through a variety of computingresources and hardware infrastructures.

While the description makes reference to specific technologies, systemarchitectures and data management techniques, practitioners willappreciate that this is but one embodiment and that other devices and/ormethods may be implemented without departing from the scope of theinvention. Similarly, while the description makes frequent reference toa web client, practitioners will appreciate that other examples ofsolicitation-response lifecycle tracking and management methods may beaccomplished by using a variety of user interfaces including handhelddevices such as personal digital assistants and cellular telephones.Practitioners will also appreciate that a web client is but oneembodiment and that other devices and/or methods may be implementedwithout departing from the scope of the invention.

With reference to FIG. 1, the system includes a user 105 interfacingwith a billing and payment management system (“BPMS”) 115 by way of aweb client 110. A user is any individual, entity, organization,third-party entity, software and/or hardware that accesses BPMS 115 toview, analyze, audit, validate, utilize, evaluate, report, enhance ormaintain data relating to the tracking and management of correspondencelifecycle tracking data. User 105 may be, for example, a strategicplanning manager using the system to analyze the customers thattypically pay an invoice within a week of receipt in the mail. User 105may interface with Internet server 125 via any communication protocol,device or method discussed herein, known in the art, or later developed.In one embodiment, user 105 may interact with the BPMS 115 via anInternet browser at a web client 110.

While described in the context of information systems for a transactionaccount issuer billing operation, practitioners will appreciate that thepresent invention may be similarly used by any organization to track andmanage a solicitation-response lifecycle. However, to simplify theexplanation, the lifecycle tracking and management functions are oftenreferenced herein in the context of tracking and maintaining billing andaccounts receivable metrics for a transaction account issuer billingoperation.

Transmissions between the user 105 and the Internet server 125 may passthrough a firewall 120 to help ensure the integrity of the BPMS 115components. Practitioners will appreciate that the invention mayincorporate any number of security schemes or none at all. In oneembodiment, the Internet server 125 receives page requests from the webclient 110 and interacts with various other system 100 components toperform tasks related to requests from the web client 110. Internetserver 125 may invoke an authentication server 130 to verify theidentity of user 105 and assign specific access rights to user 105.Authentication database 135 may store information used in theauthentication process such as, for example, user identifiers,passwords, access privileges, user preferences, user statistics, and thelike. When a request to access system 100 is received from Internetserver 125, access system 100 determines if authentication is requiredand transmits a prompt to the web client 110. User 105 entersauthentication data at the web client 110, which transmits theauthentication data to Internet server 125. Internet server 125 passesthe authentication data to authentication server which queries the userdatabase 140 for corresponding credentials. When user 105 isauthenticated, user 105 may access various applications and theircorresponding data sources.

When user 105 logs on to an application, Internet server 125 may invokean application server 145. Application server 145 invokes logic in thelifecycle management and reporting module (“LMRM”) 147 by passingparameters relating to the user's 105 requests for data.

As discussed in further detail in the process descriptions below, theLMRM 147 reads data from various databases such as, for example, thelifecycle management and reporting (“LMR”) database 160 and the customeraccount database 155. LMRM 147 may include any hardware and/or softwaresuitably configured to receive requests from the web client 110 viaInternet server 125 and the application server 145. LMRM 147 is furtherconfigured to process requests, construct database queries, and/orexecute queries against databases, external data sources and temporarydatabases, as well as exchange data with other application modules (notpictured). In one embodiment, the LMRM 147 may be configured to interactwith other system 100 components to perform complex calculations,retrieve additional data, format data into reports, create XMLrepresentations of data, construct markup language documents, and/or thelike. Moreover, the LMRM 147 may reside as a standalone system or may beincorporated with the application server 145 or any other BPMS 115component as program code.

As practitioners will appreciate, while depicted as a single entity forthe purposes of illustration, databases depicted in FIG. 1 may representmultiple physical and/or hardware, software, database, data structureand networking components. FIG. 1 depicts the types of databases thatare included in an exemplary embodiment. The customer account database155 stores tracking information, such as, for example, account numbersand receivable records, regarding customer accounts. The LMR database160 stores tracking and reporting metrics associated with the lifecycleof a receivable. In one embodiment, the lifecycle of a receivable isalso referred to as the bill-to-cash lifecycle. LMR database 160 ispopulated with data from various other data sources such as the customeraccount database 155 and the download database 175. Customer accountdatabase 155 stores billing and invoice information. Download database175 maintains a copy of the information downloaded by the data downloadmodule (“DDM”) 180. In one embodiment, DDM 180 is a software module thatlinks to the external data maintained by a service provider (e.g., ashipper such as the USPS). DDM 180 reads data from service providertracking database 185 and stores the data in download database 175.Service provider tracking database 185 is an external databasemaintained by the service provider that provides delivery and packagetracking information throughout the package delivery lifecycle.

In one embodiment, service provider tracking database 185 is the datasource provided by the USPS in connection with their “Confirm Service”product. However, as practitioners will appreciate, other embodimentsmay download data from any external data source that provides useful andaccurate data. For instance the BPMS 115 may be interconnected to anexternal data source 161 via a second network, referred to as theexternal gateway 163. The external gateway 163 may include any hardwareand/or software suitably configured to facilitate communications and/orprocess transactions between the BPMS 115 and the external data source161. Interconnection gateways are commercially available and known inthe art. External gateway 163 may be implemented through commerciallyavailable hardware and/or software, through custom hardware and/orsoftware components, or through a combination thereof External gateway163 may reside in a variety of configurations and may exist as astandalone system or may be a software component residing either insidesystem 100, the external data source 161 or any other knownconfiguration. External gateway 163 may be configured to deliver datadirectly to system 100 components (such as DDM 180) and to interact withother systems and components such as LMR database 170. In oneembodiment, external gateway 163 may comprise web services that areinvoked to exchange data between the various disclosed systems. Externalgateway 163 represents existing proprietary networks that presentlyaccommodate data exchange for data such as financial transactions,customer demographics, billing transactions and the like. Externalgateway 163 is a closed network that is assumed to be secure fromeavesdroppers.

As practitioners will appreciate, embodiments are not limited to theexemplary databases described above, nor do embodiments necessarilyutilize each of the disclosed exemplary databases. In addition to thecomponents described above, the system 100 and the BPMS 115 may furtherinclude one or more of the following: a host server or other computingsystems including a processor for processing digital data; a memorycoupled to the processor for storing digital data; an input digitizercoupled to the processor for inputting digital data; an applicationprogram stored in the memory and accessible by the processor fordirecting processing of digital data by the processor; a display devicecoupled to the processor and memory for displaying information derivedfrom digital data processed by the processor; and a plurality ofdatabases. A representative list of various databases used hereinincludes: customer account database 155, LMR database 160, downloaddatabase 175, service provider tracking database 185, an external datasource 161 and/or other databases that aid in the functioning of thesystem.

As will be appreciated by one of ordinary skill in the art, one or moresystem 100 components may be embodied as a customization of an existingsystem, an add-on product, upgraded software, a stand-alone system(e.g., kiosk), a distributed system, a method, a data processing system,a device for data processing, and/or a computer program product.Accordingly, individual system 100 components may take the form of anentirely software embodiment, an entirely hardware embodiment, or anembodiment combining aspects of both software and hardware. Furthermore,individual system 100 components may take the form of a computer programproduct on a computer-readable storage medium having computer-readableprogram code means embodied in the storage medium. Any suitablecomputer-readable storage medium may be utilized, including hard disks,CD-ROM, optical storage devices, magnetic storage devices, and/or thelike.

The invention contemplates uses in association with billing systems,accounts receivable systems, operational management systems, cashmanagement tools, logistical planning tools, business intelligencesystems, reporting systems, web services, pervasive and individualizedsolutions, open source, biometrics, mobility and wireless solutions,commodity computing, grid computing and/or mesh computing. For example,in an embodiment, the web client 110 is configured with a biometricsecurity system that may be used for providing biometrics as a secondaryform of identification. The biometric security system may include atransaction device and a reader communicating with the system. Thebiometric security system also may include a biometric sensor thatdetects biometric samples and a device for verifying biometric samples.The biometric security system may be configured with one or morebiometric scanners, processors and/or systems. A biometric system mayinclude one or more technologies, or any portion thereof, such as, forexample, recognition of a biometric. As used herein, a biometric mayinclude a user's voice, fingerprint, facial, ear, signature, vascularpatterns, DNA sampling, hand geometry, sound, olfactory,keystroke/typing, iris, retinal or any other biometric relating torecognition based upon any body part, function, system, attribute and/orother characteristic, or any portion thereof.

Web client 110 comprises any hardware and/or software suitablyconfigured to facilitate requesting, retrieving, updating, analyzing,entering or modifying data such as marketing data or any informationdiscussed herein. Web client 110 includes any device (e.g., personalcomputer), which communicates (in any manner discussed herein) with theBPMS 115 via any network discussed herein. Such browser applicationscomprise Internet browsing software installed within a computing unit orsystem to conduct online transactions and communications. Thesecomputing units or systems may take the form of a computer or set ofcomputers, although other types of computing units or systems may beused, including laptops, notebooks, hand-held computers, set-top boxes,workstations, computer-servers, mainframe computers, mini-computers, PCservers, pervasive computers, network sets of computers, and/or thelike. Practitioners will appreciate that the web client 110 may or maynot be in direct contact with the BPMS 115. For example, the web client110 may access the services of the BPMS 115 through another server,which may have a direct or indirect connection to Internet server 125.

As those skilled in the art will appreciate, the web client 110 includesan operating system (e.g., Windows NT, 95/98/2000, OS2, UNIX, Linux,Solaris, MacOS, etc.) as well as various conventional support softwareand drivers typically associated with computers. Web client 110 mayinclude any suitable personal computer, network computer, workstation,mini-computer, mainframe, mobile device or the like. Web client 110 canbe in a home or business environment with access to a network. In anembodiment, access is through a network or the Internet through acommercially available web-browser software package.

Web client 110 may be independently, separately or collectively suitablycoupled to the network via data links which includes, for example, aconnection to an Internet Service Provider (ISP) over the local loop asis typically used in connection with standard modem communication, cablemodem, Dish networks, ISDN, Digital Subscriber Line (DSL), or variouswireless communication methods, see, e.g., Gilbert Held, UnderstandingData Communications (1996), which is hereby incorporated by reference.It is noted that the network may be implemented as other types ofnetworks, such as an interactive television (ITV) network.

Firewall 120, as used herein, may comprise any hardware and/or softwaresuitably configured to protect the BPMS 115 components from users ofother networks. Firewall 120 may reside in varying configurationsincluding stateful inspection, proxy-based and packet filtering, amongothers. Firewall 120 may be integrated as software within Internetserver 125, any other system components, or may reside within anothercomputing device or may take the form of a standalone hardwarecomponent.

Internet server 125 may include any hardware and/or software suitablyconfigured to facilitate communications between the web client 110 andone or more BPMS 115 components. Further, Internet server 125 may beconfigured to transmit data to the web client 110 within markup languagedocuments. As used herein, “data” may include encompassing informationsuch as commands, queries, files, data for storage, and/or the like indigital or any other form. Internet server 125 may operate as a singleentity in a single geographic location or as separate computingcomponents located together or in separate geographic locations.

Internet server 125 may provide a suitable web site or otherInternet-based graphical user interface, which is accessible by users.An Internet server may provide a suitable web site or otherInternet-based graphical user interface which is accessible by users. Inone embodiment, the Microsoft Internet Information Server (IIS),Microsoft Transaction Server (MTS), and Microsoft SQL Server, are usedin conjunction with the Microsoft operating system, Microsoft NT webserver software, a Microsoft SQL Server database system, and a MicrosoftCommerce Server. Additionally, components such as Access or MicrosoftSQL Server, Oracle, Sybase, Informix MySQL, InterBase, etc., may be usedto provide an Active Data Object (ADO) compliant database managementsystem. In one embodiment, the Apache web server is used in conjunctionwith a Linux operating system, a MySQL database, and/or the Peri, PHP,and Python programming languages.

Any of the communications, inputs, storage, databases or displaysdiscussed herein may be facilitated through a web site having web pages.The term “web page” as it is used herein is not meant to limit the typeof documents and applications that may be used to interact with theuser. For example, a typical web site may include, in addition tostandard HTML documents, various forms, Java applets, JavaScript, activeserver pages (ASP), Microsoft .NET Framework, common gateway interfacescripts (CGI), extensible markup language (XML), dynamic HTML, AJAX(Asynchronous Javascript And XML), cascading style sheets (CSS), helperapplications, plug-ins, and/or the like. A server may include a webservice that receives a request from a web server, the request includinga URL (http://yahoo.com/stockquotes/ge) and an IP address (123.56.789).The web server retrieves the appropriate web pages and sends the data orapplications for the web pages to the IP address. Web services areapplications that are capable of interacting with other applicationsover a communications means, such as the Internet. Web services aretypically based on standards or protocols such as XML, SOAP, AJAX, WSDLand UDDI. Web services methods are well known in the art, and arecovered in many standard texts. See, e.g., ALEX NGHIEM, IT WEB SERVICES:A ROADMAP FOR THE ENTERPRISE (2003) or WEB SERVICES ARCHITECTURE, W3CWorking Group Note 11 Feb. 2004, available athttp://www.w3.org/TR/2004/NOTE-ws-arch-20040211, both of which arehereby incorporated by reference.

Application server 145 may include any hardware and/or software suitablyconfigured to serve applications and data to a connected web client 110.Like Internet server 125, the application server 145 may communicatewith any number of other servers, databases and/or components throughany means known in the art. Further, the application server 145 mayserve as a conduit between the web client 110 and the various systemsand components of the BPMS 115. Internet server 125 may interface withthe application server 145 through any means known in the art includinga LAN/WAN, for example. Application server 145 may further invokesoftware modules such as the LMRM 147 in response to user 105 requests.

In order to control access to the application server 145 or any othercomponent of the BPMS 115, Internet server 125 may invoke anauthentication server 130 in response to user 105 submissions ofauthentication credentials received at Internet server 125.Authentication server 130 may include any hardware and/or softwaresuitably configured to receive authentication credentials, encrypt anddecrypt credentials, authenticate credentials, and/or grant accessrights according to pre-defined privileges attached to the credentials.Authentication server 130 may grant varying degrees of application anddata level access to users based on information stored within the userdatabase 140.

Any database depicted or implied by FIG. 1 may include any hardwareand/or software suitably configured to facilitate storingidentification, authentication credentials, and/or user permissions. Oneskilled in the art will appreciate that system 100 may employ any numberof databases in any number of configurations. Further, any databasesdiscussed herein may be any type of database, such as relational,hierarchical, graphical, object-oriented, and/or other databaseconfigurations. Common database products that may be used to implementthe databases include DB2 by IBM (White Plains, N.Y.), various databaseproducts available from Oracle Corporation (Redwood Shores, Calif.),Microsoft Access or Microsoft SQL Server by Microsoft Corporation(Redmond, Wash.), Microsoft Office SharePoint Server, or any othersuitable database product. Moreover, the databases may be organized inany suitable manner, for example, as data tables or lookup tables. Eachrecord may be a single file, a series of files, a linked series of datafields or any other data structure. Association of certain data may beaccomplished through any desired data association technique such asthose known or practiced in the art. For example, the association may beaccomplished either manually or automatically. Automatic associationtechniques may include, for example, a database search, a databasemerge, GREP, AGREP, SQL, using a key field in the tables to speedsearches, sequential searches through all the tables and files, sortingrecords in the file according to a known order to simplify lookup,and/or the like. The association step may be accomplished by a databasemerge function, for example, using a “key field” in pre-selecteddatabases or data sectors.

More particularly, a “key field” partitions the database according tothe high-level class of objects defined by the key field. For example,certain types of data may be designated as a key field in a plurality ofrelated data tables and the data tables may then be linked on the basisof the type of data in the key field. The data corresponding to the keyfield in each of the linked data tables is preferably the same or of thesame type. However, data tables having similar, though not identical,data in the key fields may also be linked by using AGREP, for example.In accordance with one aspect of the invention, any suitable datastorage technique may be utilized to store data without a standardformat. Data sets may be stored using any suitable technique, including,for example, storing individual files using an ISO/IEC 7816-4 filestructure; implementing a domain whereby a dedicated file is selectedthat exposes one or more elementary files containing one or more datasets; using data sets stored in individual files using a hierarchicalfiling system; data sets stored as records in a single file (includingcompression, SQL accessible, hashed via one or more keys, numeric,alphabetical by first tuple, etc.); Binary Large Object (BLOB); storedas ungrouped data elements encoded using ISO/IEC 7816-6 data elements;stored as ungrouped data elements encoded using ISO/IEC Abstract SyntaxNotation (ASN.1) as in ISO/IEC 8824 and 8825; and/or other proprietarytechniques that may include fractal compression methods, imagecompression methods, etc.

In an embodiment, the ability to store a wide variety of information indifferent formats is facilitated by storing the information as a BLOB.Thus, any binary information can be stored in a storage space associatedwith a data set. As discussed above, the binary information may bestored on the financial transaction instrument or external to butaffiliated with the financial transaction instrument. The BLOB methodmay store data sets as ungrouped data elements formatted as a block ofbinary via a fixed memory offset using either fixed storage allocation,circular queue techniques, or best practices with respect to memorymanagement (e.g., paged memory, least recently used, etc.). By usingBLOB methods, the ability to store various data sets that have differentformats facilitates the storage of data associated with the system bymultiple and unrelated owners of the data sets. For example, a firstdata set which may be stored may be provided by a first party, a seconddata set which may be stored may be provided by an unrelated secondparty, and yet a third data set which may be stored, may be provided bya third party unrelated to the first and second parties. Each of thethree data sets in this example may contain different information thatis stored using different data storage formats and/or techniques.Further, each data set may contain subsets of data that also may bedistinct from other subsets.

As stated above, in various embodiments of system 100, the data can bestored without regard to a common format. However, in one embodiment ofthe invention, the data set (e.g., BLOB) may be annotated in a standardmanner when provided for manipulating the data onto the financialtransaction instrument. The annotation may comprise a short header,trailer, or other appropriate indicator related to each data set that isconfigured to convey information useful in managing the various datasets. For example, the annotation may be called a “condition header”,“header”, “trailer”, or “status”, herein, and may comprise an indicationof the status of the data set or may include an identifier correlated toa specific issuer or owner of the data. In one example, the first threebytes of each data set BLOB may be configured or configurable toindicate the status of that particular data set; e.g., LOADED,INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED. Subsequent bytes ofdata may be used to indicate for example, the identity of the issuer,user, transaction/membership account identifier or the like. Each ofthese condition annotations are further discussed herein.

The data set annotation may also be used for other types of statusinformation as well as various other purposes. For example, the data setannotation may include security information establishing access levels.The access levels may, for example, be configured to permit only certainindividuals, levels of employees, companies, or other entities to accessdata sets, or to permit access to specific data sets based on thetransaction, merchant, issuer, user or the like. Furthermore, thesecurity information may restrict/permit only certain actions such asaccessing, modifying, and/or deleting data sets. In one example, thedata set annotation indicates that only the data set owner or the userare permitted to delete a data set, various identified users may bepermitted to access the data set for reading, and others are altogetherexcluded from accessing the data set. However, other access restrictionparameters may also be used allowing various entities to access a dataset with various permission levels as appropriate.

The data, including the header or trailer may be received by astand-alone interaction device configured to add, delete, modify, oraugment the data in accordance with the header or trailer. As such, inone embodiment, the header or trailer is not stored on the transactiondevice along with the associated issuer-owned data but instead theappropriate action may be taken by providing to the transactioninstrument user at the stand-alone device, the appropriate option forthe action to be taken. System 100 contemplates a data storagearrangement wherein the header or trailer, or header or trailer history,of the data is stored on the transaction instrument in relation to theappropriate data.

One skilled in the art will also appreciate that, for security reasons,any databases, systems, devices, servers or other components of system100 may consist of any combination thereof at a single location or atmultiple locations, wherein each database or system includes any ofvarious suitable security features, such as firewalls, access codes,encryption, decryption, compression, decompression, and/or the like.

The invention may be described herein in terms of functional blockcomponents, screen shots, optional selections and various processingsteps. It should be appreciated that such functional blocks may berealized by any number of hardware and/or software components configuredto perform the specified functions. For example, system 100 may employvarious integrated circuit components, e.g., memory elements, processingelements, logic elements, look-up tables, and/or the like, which maycarry out a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, the softwareelements of system 100 may be implemented with any programming orscripting language such as C, C++, Java, COBOL, assembler, PERL, VisualBasic, SQL Stored Procedures, extensible markup language (XML), with thevarious algorithms being implemented with any combination of datastructures, objects, processes, routines or other programming elements.Further, it should be noted that system 100 may employ any number ofconventional techniques for data transmission, signaling, dataprocessing, network control, and/or the like. Still further, system 100could be used to detect or prevent security issues with a client-sidescripting language, such as JavaScript, VBScript or the like. For abasic introduction of cryptography and network security, see any of thefollowing references: (1) “Applied Cryptography: Protocols, Algorithms,And Source Code In C,” by Bruce Schneier, published by John Wiley & Sons(Second edition, 1995); (2) “Java Cryptography” by Jonathan Knudson,published by O'Reilly & Associates (1998); (3) “Cryptography & NetworkSecurity: Principles & Practice” by William Stallings, published byPrentice Hall; all of which are hereby incorporated by reference.

These software elements may be loaded onto a general purpose computer,special purpose computer, or other programmable data processingapparatus to produce a machine, such that the instructions that executeon the computer or other programmable data processing apparatus createmeans for implementing the functions specified in the flowchart block orblocks. These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions. Further, illustrations ofthe process flows and the descriptions thereof may make reference touser windows, web pages, web sites, web forms, prompts, etc.Practitioners will appreciate that the illustrated steps describedherein may comprise in any number of configurations including the use ofwindows, web pages, web forms, popup windows, prompts and/or the like.It should be further appreciated that the multiple steps as illustratedand described may be combined into single web pages and/or windows buthave been expanded for the sake of simplicity. In other cases, stepsillustrated and described as single process steps may be separated intomultiple web pages and/or windows but have been combined for simplicity.

Practitioners will appreciate that there are a number of methods fordisplaying data within a browser-based document. Data may be representedas standard text or within a fixed list, scrollable list, drop-downlist, editable text field, fixed text field, pop-up window, and/or thelike. Likewise, there are a number of methods available for modifyingdata in a web page such as, for example, free text entry using akeyboard, selection of menu items, check boxes, option boxes, and/or thelike.

Referring now to the figures, the block system diagrams and process flowdiagrams represent mere embodiments of the invention and are notintended to limit the scope of the invention as described herein. Forexample, the steps recited in FIGS. 2-4 may be executed in any order andare not limited to the order presented. It will be appreciated that thefollowing description makes appropriate references not only to the stepsdepicted in FIGS. 2-4, but also to the various system components asdescribed above with reference to FIG. 1.

With reference to FIG. 2, a representative process for tracking thelifecycle of a communication with a customer is shown. The lifecycle mayinvolve any interaction between an organization and anotherorganization. For instance, a lifecycle may involve sending a marketingsolicitation, a consumer survey or a bill to a customer or potentialcustomer and receiving a response. In one embodiment, a billingorganization generates a bill and a receivable is generated to indicatethat the organization expects to receive payment by the respondingentity (e.g. a customer) (Step 205). Tracking data is generated in orderto track the movement of the bill and its associated components (e.g.the remittance portion of the bill) throughout the payment lifecycle.

In the representative embodiment illustrated in FIG. 2, LMRM 147generates two tracking data sets, one for tracking the invoice portionof the bill and one for tracking the remittance portion of the bill, andstores the tracking datasets in LMR database 170 (Step 210). Theinformation in separate tracking datasets is linked using codes,referential lookup tables, pointers or any other technique known in theart suitable for linking or associating data. The present invention doesnot require multiple tracking data sets; other embodiments may generateonly one tracking dataset. For instance, a single tracking datasetcapable of maintaining multiple origin and destination data may be usedto track both the invoice and remittance of a customer bill.

The bill is encoded with an indicator which represents the data from thetracking dataset. For instance, in one embodiment, LMRM 147 encodes theinformation from the invoice tracking dataset in an IMB which is printedon the invoice envelope (Step 215). Similarly, LMRM 147 encodes theinformation from the remittance tracking dataset which is printed on theremittance portion of the bill (Step 216). The invention is not limitedto using an IMB as the indicator. The indicator may take any form orformat, as disclosed herein. For instance, in one embodiment, an RFID isused to track the movement of the solicitation through the lifecycle. Inthe context of conducting a survey, an RFID is attached to the surveyand the survey is tracked as it completes the loop from the solicitingorganization to the responding entity (i.e. the entity being surveyed)and to the organization collecting the survey data.

Continuing with the representative embodiment in FIG. 2, the trackingindicators are printed as an IMB on portions of the bill (Steps 215,216). However, other embodiments of the present invention may notinclude printing as the means for associating the indicator with thesolicitation. In other embodiments the indicator, in any of its variousforms disclosed above, may be suitably attached or associated to anyportion of the solicitation such that the indicator is capable of beingdetected. For instance, IMB's may be printed on the bill and remittancethemselves and the corresponding envelopes may have a window, apertureor other suitable structure that allows the IMB's to be scanned. Asdiscussed above, other embodiments use other types of indicators.Therefore, as practitioners will appreciate, attaching or associatingthe indicator with the solicitation such that it is capable of beingdetected as it traverses the lifecycle may be accomplished using anysuitable means.

As the solicitation traverses the lifecycle from the solicitingorganization to the responding entity and to the ultimate point oftermination, the indicators associated with the solicitation aredetected at any point. The information detected is stored or transmittedsuch that the soliciting organization has access to the information. Aspractitioner's will appreciate, the invention is not limited by the typeof solicitation, the entity detects the indicator or the number ofentities and/or steps in a lifecycle. For example, the one solicitationmay result in multiple responses, all of which are tracked and linked toeach other. In one embodiment, a market research organization sends apackage of coupons to a company who distributes the coupons to itsemployees and the response is tracked when the coupon is redeemed.Moreover, in one embodiment, multiple solicitations may be linked toeach other which may be linked to a single or to multiple responses.

As the solicitation traverses the lifecycle from the solicitingorganization to the responding entity, and to the ultimate point oftermination, the indicators associated with the solicitation aredetected. The information detected is stored or transmitted such thatthe soliciting organization has access to the information. In therepresentative embodiment illustrated in FIG. 2, the solicitation is acustomer bill, the soliciting organization is the billing organizationand the indicator is detected by the USPS. The billing organizationplaces the bill in the USPS mail and the USPS tracks the bill throughthe delivery process by scanning the indicator. The USPS performs anorigination scan of the invoice tracking indicator on the bill'senvelope (Step 220). At the USPS destination facility the USPS performsa destination scan just prior to the bill arriving at the customeraddress for delivery (Step 225). The customer receives the invoice inthe mail (Step 230).

The customer pays the bill and places the remittance envelope in themail

(Step 235). USPS picks up the remittance envelope and performs anorigination scan of the remittance tracking indicator (Step 240). USPSdelivers the envelope to the remittance address and performs a deliveryscan on the remittance tracking indicator (Step 245). The billingorganization tracks the progress of the payment as it is processed andposted to the organization's customer account database 155 (Step 250).As illustrated in FIG. 2, each time the USPS scans the trackingindicator (i.e. the IMB in this example), the information that isdetected in the scan, along with additional information indicating thetime, location and other data is stored in the USPS tracking database185.

Information detected and stored during the solicitation lifecycle isstored or transmitted such that the soliciting organization has accessto the tracking information. As discussed above, in one embodiment, theUSPS detects the indicator, augments the detected data with additionaltracking data and stores all the data on the service provider trackingdatabase 185 (Steps 220, 225, 240, 245 and 250). As practitioners willappreciate, tracking the progress of a solicitation as it travels fromone location to another is not limited to the USPS and may be performedby a wide variety of service providers. For instance, in one embodiment,a wireless communication provider detects an indicator that is a GPSsignal, detects the data encoded in the signal, augments it withadditional data (e.g. time, location and status corresponding to thedetection) and stores the tracking data on their own database or on athird-party database. In one embodiment, tracking data is transmitteddirectly to the organization that originated the solicitation.

The tracking data is received by the soliciting organization. In theembodiment shown in FIG. 3, the DDM 180 coordinates the transfer ofinformation from the service provider tracking database 185 to thedownload database 175 (Step 305). In one embodiment, the data isdownloaded using file transfer protocol (FTP). However, as practitionerswill appreciate, the data transfer may be accomplished in a variety ofupload, download and data transfer methods. In another embodiment, thedata is transmitted directly to the soliciting organization's database,so the file transfer (such as that depicted in Step 305) may not occur.LMRM 147 matches the bill tracking data (generated in Step 210) whichwas used to encode the bill tracking indicators (Steps 215 and 216) todata in the download database 175 (Step 310). In one embodiment, thecustomer account and bill number stored as bill tracking data in LMRM147 is matched with tracking event records in the download database 175.In one embodiment, LMRM also matches data to data stored in customeraccount database 155 (Step 310). LMRM matches the data indicationlocation in download database 175 to the location data stored in LMR 170(Step 315). LMRM 147 updates LMR 170 with the account, bill and locationmatching data. LMRM reads a receivable event (Step 205) and/or a remitevent (Step 250), as shown in FIG. 2, from customer account database 155and updates bill tracking data in LMR 170 (Step 325), as shown in FIG.3. With respect to FIG. 3, the matching steps produce a complete set ofbill payment tracking data which is valuable in the process of FIG. 4for calculating statistics and understanding customer payment habits.“Matched tracking data” includes data that has been processed, validatedand/or matched (for example, as represented in one embodiment, by theprocess of FIG. 3) such that the data is appropriately linked andaugmented to a form that is useful and valuable to an organization.

FIG. 4 illustrates a representative process of using matched trackingdata and mapping it to business events and statistics to create valuableoperational analytical data. In one embodiment, LMRM 147 reads matchedtracking data and maps the data to operational events and calculatescustomer bill payment statistics to produce granular data that moreaccurately reveals the full bill-to-payment lifecycle for anorganization such as a transaction account issuer (e.g. a bank). Theevent that shows the account receivable record being created (Step 205)is Time 0 (T₀) (Step 405). The event that corresponds to the originationscan of the indicator on the invoice envelope (Step 220) is T₁ (Step415). The difference between these times (T₁−T₀) represents the totaltime used by the organization to generate the bill and prepare it formailing to the customer (Step 410). Similar calculations are made foreach subsequent event in the bill payment tracking data for times T₁through T₅. At T₂, the invoice is delivered to the customer, and at T₃,the remittance is mailed by the customer. The difference between thesetwo events (T₃−T₂) is a period of time of particular interest to anorganization. Existing systems and methods provide little or novisibility into this time period. In the representative embodiment shownin FIG. 4, the invoice tracking data and the remittance tracking dataare linked at the time they are generated and the data used to establishthe link is stored in LMR database 170 (Step 210) and encoded in theindicators. (Steps 215 and 216).

With reference to FIG. 5, a representative process for tracking asolicitation throughout a multi-stage process (e.g., internal processingsuch as a billing process and an external process such as a shippingprocess) is shown. In one embodiment, a billing organization generates abill and a receivable is generated to indicate that the organizationexpects to receive payment by the responding entity (e.g. a customer)(Step 505). Tracking data is generated in order to track the movement ofthe bill and its associated components (e.g. the remittance portion ofthe bill) throughout the payment lifecycle.

In the representative embodiment illustrated in FIG. 5, LMRM 147generates a payment lifecycle tracking dataset and stores it in LMRdatabase 170 (Step 510). The payment lifecycle tracking dataset isassociated with an invoice tracking identifier. In one embodiment,multiple tracking data sets are used to track the lifecycle data and thedata sets are associated with each other using the invoice trackingidentifier or some other code.

The bill is encoded with the invoice tracking indicator. For instance,in one embodiment, LMRM 147 encodes the information from the invoicetracking dataset as an indicator, such as a bar code or an IMB, which isprinted on the invoice envelope (Step 515). Similarly, LMRM 147 encodesan indicator with the invoice tracking identifier on the remittanceportion of the bill (Step 516). The invention is not limited to using anIMB as the indicator. The indicator may take any form or format, asdisclosed herein (e.g., an intelligent mail barcode, a radio frequencyidentifier (RFID), a global positioning system signal, a signal, a code,device, number, letter, symbol, digital certificate, smart chip, digitalsignal, analog signal, biometric, PIN, Internet code, magnetic stripe,optical, and transponder).

Continuing with the representative embodiment in FIG. 5, the trackingindicators are printed as a bar code on portions of the bill (Steps 515,516). However, other embodiments may not include printing as the meansfor associating the indicator with the solicitation. In otherembodiments, the indicator (in any of its various forms disclosed above)may be suitably attached or associated to any portion of thesolicitation such that the indicator is capable of being detected. Forinstance, IMBs may be printed on the bill and remittance themselves andthe corresponding envelopes may have a window, aperture or othersuitable structure that allows the IMBs to be scanned. As discussedabove, other embodiments use other types of indicators. Therefore, aspractitioners will appreciate, attaching or associating the indicatorwith the solicitation such that it is capable of being detected as ittraverses the lifecycle may be accomplished using any suitable means.

In one embodiment, it may be impractical or unfeasible to opticallydetect the indicator during certain points of the lifecycle. Forinstance, a large number of bills (and/or envelopes containing bills)may be stacked together such that optically detecting the individualparcel may be impractical or inefficient. This situation is present inmany processes that send out solicitations (e.g., bills) in bulk. Thepre-shipping process often involves one or more grouping and/or sortingsteps where a number of parcels are stacked together. In order toprovide process tracking data for these steps, an additional indicatorthat may be detected non-optically enhances process efficiency andcollection of useful, granular data. In the embodiment illustrated inFIG. 5, an RFID tag, that is attached to or contained within either thebill or the envelope, is associated with the invoice tracking indicator(Step 520).

As the bill traverses the lifecycle from the soliciting organization tothe responding entity, and to the ultimate point of termination, theindicators associated with the solicitation are detected. Theinformation detected is stored or transmitted such that the solicitingorganization has access to the information. In the representativeembodiment illustrated in FIG. 5, the solicitation is a customer bill,the soliciting organization is the billing organization and theindicator is detected by the USPS. The billing organization tracksindividual bills throughout each step of the pre-shipping processes(Step 525). In one embodiment, pre-shipping processes include insertingthe bill into an envelope, one or more pre-sorting steps, registrationwith the service provider booking system (e.g., the USPS's automatedmail booking system), and one or more staging area trays or holdingqueues. At various points during these process steps, exact location anddate/time data is collected by detecting individual parcels either bydetecting an indicator or by sensing the RFID tag.

In one embodiment, tracking the exact moment that a bill leaves thebilling organization is tracked for regulatory compliance purposes.Thus, an RFID scan occurs as the bill moves across a control boundarybetween the billing organization and the service provider (Step 530).The service provider tracks the bill through the delivery process eitherby scanning the indicator or by detecting the RFID tag (Step 535). Thedata is collected, matched and analyzed similar to the processesdisclosed above in conjunction with FIGS. 2-4.

Existing systems do not directly track the event corresponding to themailing of the remittance. Rather, in existing systems, calculating thetime the customer takes to pay a bill after receiving an invoice isbased upon when the organization receives the remittance envelope in themail. Therefore, it is not possible to calculate with certainty the truetime that the customer takes to pay the bill. At best, an organizationestimates the average mail time and subtracts that time from the totalduration between when the invoice was delivered to the customer to whenthe organization receives payment. The more granular data disclosedherein is invaluable to organizations that rely on a substantiallycomplete and accurate picture of customer payment activity. Manyorganizations use this information to drive marketing strategy,prioritize billing operations, manage cash flow expectations, etc.

While the steps outlined above represent a specific embodiment of theinvention, practitioners will appreciate that there are any number ofcomputing algorithms and user interfaces that may be applied to createsimilar results. The steps are presented for the sake of explanationonly and are not intended to limit the scope of the invention in anyway.

Benefits, other advantages, and solutions to problems have beendescribed herein with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any element(s) that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as critical, required, or essentialfeatures or elements of any or all the claims of the invention. Itshould be understood that the detailed description and specificexamples, indicating exemplary embodiments of the invention, are givenfor purposes of illustration only and not as limitations. Many changesand modifications within the scope of the instant invention may be madewithout departing from the spirit thereof, and the invention includesall such modifications. Corresponding structures, materials, acts, andequivalents of all elements in the claims below are intended to includeany structure, material, or acts for performing the functions incombination with other claim elements as specifically claimed. The scopeof the invention should be determined by the appended claims and theirlegal equivalents, rather than by the examples given above. Reference toan element in the singular is not intended to mean “one and only one”unless explicitly so stated, but rather “one or more.” Moreover, where aphrase similar to ‘at least one of A, B, or C’ is used in the claims, itis intended that the phrase be interpreted to mean that A alone may bepresent in an embodiment, B alone may be present in an embodiment, Calone may be present in an embodiment, or that any combination of theelements A, B and C may be present in a single embodiment; for example,A and B, A and C, B and C, or A and B and C.

1-20. (canceled)
 21. A method, comprising: receiving, by a computersystem, request data associated with a request transmitted from a senderto a receiver and corresponding response data associated with a responsetransmitted from the receiver to the sender corresponding to therequest; based on the request data and the corresponding response data,the computer system determining one or more behavior parameterscorresponding to the receiver; and the computer system determining,based on the one or more receiver behavior parameters, particularcontent included in a subsequent request from the sender to thereceiver.
 22. The method of claim 21, further comprising: the computersystem calculating, based on the corresponding response data, a timeinterval associated with transmitting the response; and the computersystem determining, based on the time interval, a particular parameterrelated to a response behavior of the receiver.
 23. The method of claim21, further comprising: transmitting to the receiver, by the computersystem, a tracking component configured to identify a location of therequest; subsequent to the transmitting, the computer system detectingthat the tracking component has been identified at a particularlocation; and in response to the detecting, the computer systeminstructing that a portion of the request data associated with theparticular location be download to the computer system.
 24. The methodof claim 21, further comprising: based on identification informationindicating that an identifier included in the response has beendetected, the computer system associating, based on the identifier, therequest with the response.
 25. The method of claim 21, furthercomprising: based on the request data and the corresponding responsedata, the computer system generating a transmission chronology of therequest and the response; and based on the chronology, the computersystem implementing a schedule for transmitting the subsequent request.26. The method of claim 21, wherein the request includes a paymentrequest, and the method further comprises: based on the one or morebehavior parameters, the computer system determining an incentive thatis included in a subsequent payment request, wherein the incentivefacilitates the receiver in transmitting a subsequent correspondingresponse within a particular time interval.
 27. The method of claim 21,further comprising: the computer system identifying, based on therequest data, a movement of the request from a first location to asecond location; and based on the movement, the computer systempredicting a transient time for transmitting the response to thereceiver.
 28. The method of claim 21, further comprising: the computersystem applying the request data and the corresponding response data toa statistical analysis; and the computer system determining the one ormore behavior parameters that correspond to a result of the statisticalanalysis.
 29. The method of claim 21, further comprising: the computersystem receiving, from a different computer system, informationindicating that a wireless signal identifying the response has beendetected by the different computer system; and in response to thecomputer system receiving the information from the different computersystem, the computer system instructing the different computer system toprovide at least a portion of the request data.
 30. A computer system,comprising: a processor; and a memory configured to communicate with theprocessor, the memory having instructions stored thereon that areexecutable by the processor to cause the computer system to performoperations comprising: calculating a first time interval and a secondtime interval respectively associated with providing a message to a userand receiving a response to the message from the user; based on thefirst and second time intervals, identifying one or more behaviorparameters corresponding to the user; and generating, based on the oneor more behavior parameters, particular content included in a subsequentmessage to the user.
 31. The computer system of claim 30, wherein theoperations further comprise: based on the second time interval,determining a response time associated with responding to the message bythe user; and based on the response time, identifying the one or morebehavior parameters indicative of a procrastinating behavior associatedwith the user.
 32. The computer system of claim 30, wherein theoperations further comprise: based on a difference between the first andsecond time intervals, calculating a lag time between providing themessage to the user and receiving the response from the user; andgenerating the particular content that facilitates a reduction in thelag time.
 33. The computer system of claim 30, wherein the operationsfurther comprise: in response to receiving from the user a subsequentresponse to the subsequent message, determining whether at least one ofthe one or more behavior parameter has changed in association with thesubsequent response.
 34. The computer system of claim 30, wherein theoperations further comprise: based on a satellite-based locationidentifier included in the response, identifying one or more particularlocations associated with the response; and based on the one or moreparticular locations, constructing a delivery route for the response.35. An article of manufacture including a non-transitory computerreadable medium having instructions stored thereon that are executableto cause a computer system to perform operations comprising: based oninformation indicating that a first communication has been transmittedfrom a first user to a plurality of other users, matching the firstcommunication with a second communication subsequently received by thefirst user; determining, based on the second communication, at least onebehavior parameter for one of the plurality of other users; andgenerating, based on the at least one behavior parameter, particularcontent included in a third communication transmitted from the firstuser to at least a portion of the plurality of other users.
 36. Thearticle of manufacture of claim 35, wherein the operations furthercomprise: transmitting the first communication to the plurality of otherusers, wherein the first communication includes a first identifier thatuniquely identifies the first communication; and based on identifierinformation indicating that a portion of the first identifier is incommon with a portion of a second identifier that is included in thesecond communication, determining the first and second communicationsmatch.
 37. The article of manufacture of claim 35, wherein theoperations further comprise: upon determining that the first user hasnot received a response to the first communication from one of theplurality of other users within a threshold time interval, instructing adefault response be transmitted to the first user as the secondcommunication; and based on the default response, determining the atleast one behavior parameter indicative of a nonresponsive behavior ofthe one of the plurality of other users.
 38. The article of manufactureof claim 35, wherein the operations further comprise: receiving locationinformation indicating that an optical identifier included in the secondcommunication has been detected at a first location and a secondlocation; and based on a difference between the first and secondlocations, determining that the second communication has beentransmitted from the one of the plurality of other users to the firstuser.
 39. The article of manufacture of claim 35, wherein the operationsfurther comprise: generating the first communication such that the firstcommunication includes a first tracking indicator that facilitatestracking of the first communication and a second tracking indicator thatfacilitates tracking of another communication; and in response todetermining that the second communication includes the second trackingindicator, determining that the second communication matches the firstcommunication.
 40. The article of manufacture of claim 35, wherein theoperations further comprise: receiving timing information indicatingthat the first communication was transmitted to the one of the pluralityof other users at a particular arrival time and that the secondcommunication was transmitted from the one of the plurality of the otherusers at a particular departure time; based on a different between theparticular arrival time and the particular departure time, determiningthe at least on behavior parameter corresponding to the difference; andgenerating the particular content that facilitates a predicted change inthe at least one behavior parameter.